Web Compatibility Assessment

1. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (L95-L101) — severity: error
   video.requestVideoFrameCallback(...) is called unguarded. If this API is unavailable in any supported runtime/WebView build, play() rejects before state transition logic runs, causing toggle/ended handlers to fail (and likely emit unhandled promise rejections). This maps to Platform-Specific Breakage / Missing APIs.

2. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (L95-L101, L133-L144) — severity: warning
   frameReady is awaited even when video.play() throws. In failure modes where playback never starts (decode/network/autoplay edge cases), the frame callback may never fire, leaving toggle()/end() suspended and UI state stuck. This is a Timing/Race compatibility risk because transition completion now depends on a callback that may not resolve.

3. special-pages/pages/onboarding/app/v4/components/StepHeader.module.css (L19, L32), special-pages/pages/onboarding/app/v4/components/Bubble.js (L147), special-pages/pages/onboarding/app/v4/components/Bubble.module.css (L40) — severity: info
   These visual-only changes (left alignment and staggered fade delay via CSS custom property) are low compatibility risk and do not alter browser API contracts.

Security Assessment

No direct security findings in this diff.

• No changes to captured globals, wrapper utilities, message bridge, origin validation, or transport code.
• No new postMessage, network fetch/XHR, dynamic code execution, or config-trust boundary changes.
• Changed logic is isolated to onboarding special-page UI behavior.

Risk Level

Medium Risk — UI-only scope, but the new requestVideoFrameCallback dependency introduces a real cross-runtime compatibility failure mode that can block step transitions.

Recommendations

1. Add capability/error hardening around first-frame wait: guard requestVideoFrameCallback and ensure play() always resolves/rejects deterministically (do not await an unresolvable frame promise).
2. Add an integration test path that simulates missing requestVideoFrameCallback and a video.play() rejection, and assert the toggle flow still reaches a settled state.
3. Catch/handle async handler failures in toggle()/end() call paths to prevent unhandled promise rejection noise and silent stuck states.

  

_{Sent by Cursor Automation: Web compat and sec}

Web Compatibility Assessment

1. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (approx. lines 95-101) — severity: error
   video.requestVideoFrameCallback(...) is called unconditionally. This API is not universally available across all embedded WebView/Safari baselines, so play() can reject via a TypeError path and break the toggle flow on unsupported runtimes. This is a direct platform-specific missing API regression risk.

2. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (approx. lines 95-101, 131-145) — severity: warning
   frameReady is awaited even when video.play() fails. In failure/no-decode paths, the frame callback may never fire, so toggle() / end() can stall and leave UI state stuck. This is a timing/race contract issue: state transitions depend on an await that may never resolve.

Security Assessment

No security findings in this diff. Changes are isolated to onboarding special-page UI/CSS and do not modify message bridge, origin validation, captured globals, wrapper utilities, or injected feature shims.

Risk Level

High Risk — while scope is limited to onboarding, this introduces a new platform API dependency in the video transition path without capability checks, which can cause user-visible functional breakage on unsupported WebViews.

Recommendations

1. Guard requestVideoFrameCallback with capability detection before use, and keep state transition logic functional when unavailable.
2. Do not await frameReady after failed play(); ensure toggle/end always reach a deterministic state transition.
3. Add integration coverage for: missing requestVideoFrameCallback and rejected video.play() to verify no stuck phase/reverse state.

  

_{Sent by Cursor Automation: Web compat and sec}

Bugbot Autofix prepared fixes for all 3 issues found in the latest run.

• ✅ Fixed: Play failure causes indefinite hang via unresolved promise
  • Added playSucceeded flag to only await frameReady if video.play() succeeds, preventing indefinite hang when play fails.
• ✅ Fixed: Stale closure in async toggle after await
  • Updated toggle function to use stateRef.current instead of closure state variable, matching the pattern used in end function.
• ✅ Fixed: Auto-play timer mismatched with new fade-in delay
  • Updated timeout from 667ms to 767ms and comment to reflect the new 500ms fade-in delay (500ms + 267ms = 767ms).

Or push these changes by commenting:

@cursor push 6134e28588

diff --git a/special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js b/special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js
--- a/special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js
+++ b/special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js
@@ -93,12 +93,16 @@
         video.currentTime = 0;
         /** @type {Promise<void>} */
         const frameReady = new Promise((resolve) => video.requestVideoFrameCallback(() => resolve()));
+        let playSucceeded = false;
         try {
             await video.play();
+            playSucceeded = true;
         } catch (error) {
             console.error(error);
         }
-        await frameReady;
+        if (playSucceeded) {
+            await frameReady;
+        }
     };
 
     /** @param {HTMLVideoElement | null} video */
@@ -106,20 +110,20 @@
         if (video) video.currentTime = 0;
     };
 
-    // Auto-play after bubble entry animation (400ms delay + 267ms duration = 667ms)
+    // Auto-play after bubble entry animation (500ms delay + 267ms duration = 767ms)
     useEffect(() => {
         const id = setTimeout(
             () => {
                 play(videoFor('with'));
                 setState((prev) => ({ ...prev, phase: isReducedMotion ? 'settled' : 'playing' }));
             },
-            isReducedMotion ? 0 : 667,
+            isReducedMotion ? 0 : 767,
         );
         return () => clearTimeout(id);
     }, []); // exclude isReducedMotion from deps — must not re-fire if reduced motion changes after mount
 
     const toggle = async () => {
-        const { target, phase, reverse } = state;
+        const { target, phase, reverse } = stateRef.current;
         if (phase === 'initial') {
             // Queue or cancel a reverse so auto-play will switch to "without" once the "with" video ends
             setState({ target, phase, reverse: !reverse });

Web Compatibility Assessment

1. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (play() around requestVideoFrameCallback and await frameReady) — warning
   Unconditional video.requestVideoFrameCallback(...) use is a cross-platform compatibility risk (Missing APIs category). If this API is absent in any supported WebView/Safari baseline, it throws synchronously before the try/catch, causing toggle/end async handlers to reject.

2. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (play() error path) — warning
   frameReady is awaited even when video.play() rejects. In rejection paths, no frame callback is guaranteed, so the promise can remain pending and stall state transitions (Timing and Race Conditions + return contract expectations for async handlers).

3. special-pages/pages/onboarding/app/v4/components/Bubble.js + Bubble.module.css + SingleStep.js (fade delay plumbing) — info
   The staggered fade change is scoped to CSS custom-property timing and preserves component contracts. I do not see a site-compat regression pattern here.

4. special-pages/pages/onboarding/app/v4/components/StepHeader.module.css (text alignment) — info
   Pure presentation change (text-align: left), no API/runtime compatibility concerns.

Security Assessment

No direct security findings in this diff.

The PR does not touch injected API shims, captured globals, messaging bridge, origin checks, or any network/data-exfiltration path. Changes are localized to onboarding special-page UI behavior.

Risk Level

Medium Risk — primarily due to the new first-frame synchronization path introducing potential runtime hangs/handler rejection on unsupported API or failed playback paths.

Recommendations

1. Gate requestVideoFrameCallback with feature detection and provide a bounded fallback path (for example, resolve on loadeddata/canplay or immediate resolve after successful play()).
2. Do not await frame readiness when play() fails; short-circuit to existing state transition logic so UI cannot deadlock.
3. Add an automated test case that stubs missing requestVideoFrameCallback and a play() rejection to verify toggle/end still settle correctly.

  

_{Sent by Cursor Automation: Web compat and sec}

Web Compatibility Assessment

1. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (lines 95-101) — error
   requestVideoFrameCallback is called unguarded (video.requestVideoFrameCallback(...)). On engines where this API is absent, this throws synchronously before video.play() runs, causing the toggle/end async handlers to reject and leaving the step stuck. This maps to the Missing APIs / platform-specific breakage risk.
2. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (lines 95-101) — warning
   await frameReady runs even when video.play() rejects. If playback fails (decode/policy/media error), no frame callback is guaranteed, so the promise can remain pending and block state transitions. This creates a latent UI deadlock in the toggle flow.

Security Assessment

No security vulnerabilities found in this diff.
The changes are isolated to onboarding special-page UI/animation code and tests; no message bridge, transport/origin validation, captured-globals, network, or injected API-shimming paths were modified.

Risk Level

Medium Risk — scoped UI changes, but the new video-frame sync path introduces a real compatibility failure mode on unsupported or failed playback paths.

Recommendations

1. Guard requestVideoFrameCallback with feature detection and fall back to immediate resolve or a loadeddata/canplay-based wait.
2. Do not await frame readiness after failed play(); short-circuit to preserve state progress. A pragmatic alternative is Promise.race([frameReady, timeout]) with a short timeout.
3. Add an integration/unit test path that stubs HTMLVideoElement.prototype.requestVideoFrameCallback as undefined and asserts toggle still progresses without hanging.

  

_{Sent by Cursor Automation: Web compat and sec}

Web Compatibility Assessment

1. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (95-101) — error
   video.requestVideoFrameCallback(...) is called unconditionally. On platforms/engines where this API is missing, this throws and breaks toggle/end transitions for the Duck Player step. This is a Missing APIs / platform-specific breakage risk.

2. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (96-101, 133, 143) — error
   play() catches video.play() rejection but still awaits frameReady. If playback fails (or first frame is never produced), requestVideoFrameCallback may never resolve, causing state transitions to hang in async handlers (toggle/end). This is a timing/race/hang compatibility issue.

Security Assessment

No direct security vulnerabilities identified in this diff.

• No changes to message bridge, origin validation, captured globals, wrapper utilities, or privileged transports.
• New URL param usage (bubbleFadeInDelay) is parsed numerically before writing to CSS custom properties, so no direct script/CSS injection vector is introduced by these lines.

Risk Level

Medium Risk — UI-only scope, but the new video-frame synchronization path introduces cross-platform API availability and unresolved-promise failure modes that can break onboarding progression.

Recommendations

1. Guard requestVideoFrameCallback with feature detection and provide a fallback (loadeddata/canplay/requestAnimationFrame) before visibility swap.
2. Do not await frame readiness after video.play() rejection; fail fast to previous behavior (switch state without frame wait) or use a bounded timeout.
3. Add tests for degraded environments: missing requestVideoFrameCallback and rejected video.play() to ensure toggle/end never deadlock.

  

_{Sent by Cursor Automation: Web compat and sec}

Web Compatibility Assessment

1. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (~94-99) — warning
   requestVideoFrameCallback is invoked unguarded (video.requestVideoFrameCallback(...)) and the promise is created before the try/catch. On engines where this API is missing (or partially implemented), this throws/rejects before the guarded block, so play() can fail with no fallback frame-sync path. In this component, useEffect calls play(...) without awaiting/catching, so this can surface as unhandled rejection + broken onboarding video transition behavior on older WebView/Safari baselines.

2. special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.module.css + special-pages/pages/onboarding/integration-tests/onboarding.v4.spec.js (hidden styling and test assertion change) — info
   Switching from visibility: hidden to opacity: 0 + pointer-events: none is compatible with the new first-frame swap strategy and avoids the previous-frame flash. Test update to assert opacity is consistent with that contract.

Security Assessment

1. No security vulnerabilities found in this diff — info
   No changes touch injected-script wrapper utilities, captured globals, message bridge, transport origin checks, or config trust boundaries. No new exfiltration surfaces (postMessage('*'), eval/dynamic code, network calls) were introduced.

Risk Level

Medium Risk — UI-only scope, but the new hard dependency on requestVideoFrameCallback without capability fallback can regress behavior on unsupported or lagging embedded engines.

Recommendations

1. Add a capability-gated fallback in play():
   Use if (typeof video.requestVideoFrameCallback === 'function') for the frame-sync path; otherwise fallback to requestAnimationFrame/loadeddata (or immediate state switch) so toggling still works.

2. Move frame-ready setup inside guarded logic:
   Create frameReady inside try (or guard first) so unsupported API errors are captured and do not escape as unhandled async failures.

3. Add a test for unsupported API behavior:
   Stub HTMLVideoElement.prototype.requestVideoFrameCallback = undefined in a focused test and verify toggle/settle still transitions correctly without flash/regression.

Alternative implementation:
Instead of waiting on requestVideoFrameCallback, switch after await video.play() plus one requestAnimationFrame tick on unsupported platforms; this keeps behavior deterministic while preserving compatibility.

  

_{Sent by Cursor Automation: Web compat and sec}

Web Compatibility Assessment

• special-pages/pages/onboarding/app/v4/components/DuckPlayerContent.js (~96-98) — warning: video.requestVideoFrameCallback(...) is used without an existence check. On embedded engines where this API is missing/partial, frameReady rejects and falls into catch, which avoids a hard crash but still degrades behavior (reintroduces immediate visibility swap path) and can emit repeated console errors. This maps to the Missing APIs / platform quirks risk class.

Security Assessment

• No direct security vulnerabilities found in this diff.
• window.location.search overrides are parsed via Number.parseInt and only flow into CSS timing variables, so no obvious injection/exfiltration vector is introduced.

Risk Level

Low Risk — Changes are confined to onboarding special-page UI/timing/CSS and tests; no modifications to injected hostile-page wrappers, messaging bridge, captured globals, or security-critical initialization paths.

Recommendations

1. Add a feature-detected fallback around requestVideoFrameCallback (e.g., resolve immediately or after a single requestAnimationFrame) to avoid platform-dependent rejections and noisy logs.
2. Add/extend an integration test that runs the toggle flow with requestVideoFrameCallback unavailable (stubbed/undefined) and asserts no regression in state transitions or user-visible flashing behavior.
3. Keep the new stagger-delay query-param override as test/debug-only and avoid relying on it for production timing logic.

  

_{Sent by Cursor Automation: Web compat and sec}